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DETAILED ACTION 

1 . This Non-Final Office Action is in response to Applicant's amendment filed July 
19, 2006. Applicant's amended claims 11-13. Currently claims 1-9, 11 -1 5 and 17-20 
are pending. 

Response to Amendment 

2. The 35 U.S.C. 1 12(2) rejection of Claims 11-13 is withdrawn in response to 
Applicant's amendments to claims 11-13. 

Response to Arguments 

3. Applicant's arguments, see Last Two Paragraphs, Page 8, filed July 19, 2006, 
with respect to the rejection(s) of claim(s) 1 over Advanced Decision Environment.for 
Process Tasks (ADEPT) in view of Schuiz et al., Architecting Cross-Organizational B2B 
Integration (2000) have been fully considered and are persuasive. Therefore, the 
rejection has been withdrawn. However, upon further consideration, a new ground(s) of 
rejection is made in view of ADEPT in view of Schuiz et al. and further in view of Alturi 
et al.. Enforcing Mandatory and Discretionary Security in Workflow Management 
Systems (1996) as cited in Notice of References Cited (PTO-892) mailed March 27, 
2006 (reference u1). 

In the Applicant's remarks filed July 19, 2006 applicant challenges the 35 U.S.C. 
103(a) rejection of claims 14-15 and 17-20 over Advanced Decision Environment for 
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Process Tasks (ADEPT) in view of Workflow Management Coalition Workflow Standard 
Interoperability (1998; Remarks: Pages 9-10) specifically arguing that: 

- the Workflow Management Coalition Workflow Standard Interoperability's out- 
of-order message handling capabilities are only directed to Internet messaging (email 
MIME messaging); 

- the rejection makes improper use of hindsight reasoning; and 

- there is no suggestion or motivation to combine the cited references. 

In response to Applicant's argument that the WFMC Interoperability Standard's 
message handling capabilities only apply to the handling of email messages (MIME) the 
examiner respectfully disagrees. 

WFMC teaches "This document corresponds to the Workflow Management 
Workflow Standard - Interoperability Abstract Specification [WfMCI012]. which provides 
an abstract specification that define the functionality necessary to achieve a defined 
lewel of interoperability between two or more workflow engines. This document defines 
a binding that give concrete type definition and message format for the realization of the 
abstract specification, using internet e-mail with MIME encoding as the transport 
mechanism." (emphasis added; Section 2, Page 5) wherein the specific "transport 
mechanism'Vprotocol merely represents one of a plurality of possible message 
formats/syntax/protocol that could be used to support the communications between the 
interoperating workflow systems. For example Anderson et al.; Workflow 
Interoperability (1999; Number 3, Page 5) teach utilizing several transport 
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mechanisms/message protocols (jFlow, SWAP, etc.) to coordinate processes 
(collaborative business processes, inter-enterprise workflows, agents, cross- 
organizational workflows, etc.). 

Further it is noted that utilizing messaging to support inter-process/inter-system 
communication/collaboration in agent-based and/or workflow systems is old and very 
well known as evidenced by at least the following: 

- Chen et al., Dynamic Agents for Dynamic Service Provisioning (1998); Column 2, 
Bullet 1, Page 3; Section 3.3. Page 6; 

- Johannesson, Paul, A Process Broker Architecture for Systems Integration 
(1999); Page 5; Figure 8; and 

- BEA Weblogic Collaborate Enabler for RosettaNet (2001 ); About RosettaNet, 
Page 2; Page 86; Figure 1. 

In response to applicant's argument that the references fail to show certain 
features of applicant's invention, it is noted that the features upon which applicant. relies 
(i.e., that the inter-process communications mechanism exclude the use of the MIME 
protocol) are not recited in the rejected claim(s). Although the claims are interpreted in 
light of the specification, limitations from the specification are not read into the claims. 
See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). 

In response to applicant's argument that there is no suggestion to combine the 
references, the examiner recognizes that obviousness can only be established by 
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combining or modifying the teachings of the prior art to produce the claimed invention 
where there is some teaching, suggestion, or motivation to do so found either in the 
references themselves or in the knowledge generally available to one of ordinary skill in 
the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988) and In re 
Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). 

In this case, both the Advanced Decision Environment for Process Tasks 
(ADEPT) in view of Workflow Management Coalition Workflow Standard Interoperability 
(WFMC, 1998) are directed to the same field of endeavor (workflow management) and 
represent a common body of knowledge well known to those skilled in the art, as 
evidenced by the inventor's citing of the WFMC in at least the following article(s): Chen 
et al., Inter-Enterprise Collaborative Process Management (2000; Last Paragraph, Page 
4; Figure 4; [34], Page 18) and Chen et al.. How Agents from Different E-Commerce 
Enterprises Cooperate (2000; [26], Page 17). 

The Workflow Management Coalition, found in 1993, is a non-profit industry 
consortium of leading workflow vendors (e.g. IBM, Vitria Technology) wherein the 
coalition's charter/mission is promote and develop the use of workflow through the 
establishment of standards for software terminology, interoperability and connectivity 
between workflow products. The Workflow Management Coalition is the primary 
standards body for the workflow software market. 

In response to applicant's argument that the examiner's conclusion of 
obviousness is based upon improper hindsight reasoning, it must be recognized that 
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any judgment on obviousness is in a sense necessarily a reconstruction based upon 
hindsight reasoning. But so long as it takes into account only knowledge which was 
within the level of ordinary skill at the time the claimed invention was made, and does 
not include knowledge gleaned only from the applicant's disclosure, such a 
reconstruction is proper. See In re McLaughlin, 443 F.2d 1392. 170 USPQ 209 (CCPA 
1971). 

It is noted that the applicant did not effectively challenge the Officially Noticed 
fact(s) cited in the previous office action(s) therefore those statements as presented are 
herein after prior art. Specifically it has been established that it was old and well known 
in the art at the time of the invention: 

- to use message queues and/or Object Request Brokers to manage/facilitate 
the communication/collaboration between systems (objects, agents, etc.) as well as to 
enable peer-to-peer communications across networks; 

- to specify one or more process/workflow parameters including such 
parameters as security/access control (scope of variables, objects, etc.), initial data, or 
the like in a template (class) wherein the templates ensure that all items (processes, 
agents, contracts, roles, etc.) created (instantiated) using the template are initialized 
with the appropriate default/initial parameters; 

- to associate (include) scope (access control, security, usage, etc.) with a more 
than one agent, user, role, application, system or the like; and 
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- to utilize any of a plurality of well known mechanisms, methods, techniques 
and approaches to exception (error) handling; specifically the well-known technique for 
exception handling in which a system reviews exception messages (alerts, signals, etc.) 
as they are received, halting (interrupting) execution when the exception is detected 
(received) that matches a particular criteria or rule and not halting (continuing) the 
execution when the exception received does not meet a particular criteria rule. 



Application/Control Number: 09/823,581 Page 8 

Art Unit: 3623 

Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 103(a) which fomris the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

5. Claims 1-4, 6-9 and 11-13 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Advanced Decision Environment for Process Tasks (ADEPT) 
features, capabilities and/or characteristics of ADEPT being disclosed in at least the 
following references: 

I. Norman, T.J., et al. Designing and implementing a multi-agent architecture for 
business process management (1996) herein after reference A. 

II. Jennings, N.R. et al.. Using Intelligent Agents to Manage Business Processes 
(1996) herein after reference B. 

III. Alty, J.L. et a!., Advanced Decision Environment for Process Tasks: 
Overview and Architecture (1994) herein after reference D. 

IV. Jennings, N.R. et al., Autonomous Agents for Business Process 
Management (2000), herein after reference E. 

in view of Schuiz et al., Architecting Cross-Organizational B2B Integration (2000) 
and further in view of Atluri et al.. Enforcing Mandatory and Discretionary Security in 
Workflow Management Systems (1996). 
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Regarding Claim 1 Advanced Decision Environment for Process Tasks (ADEPT) 
teaches a computer implement method for managing a collaborative process that 
involves at least a first player in a first enterprise having a first collaborative process 
manager and a second player in a second enterprise having a second collaborative 
process manager (agents; reference A: Pages 1-11; Figures 1-4; reference B: Pages 1- 
12; Figures 1-2, 6-7 and 10; Page 9; Figures 2, 3 and 5; reference D: Pages 1-3; 
Figures 1-5) comprising: 

- defining an inter-enterprise collaborative business process including templates 
(definitions, standards, process definitions, SLA templates, etc.; reference E: 
Paragraphs 1-2, Page 156) and having a plurality of work nodes (agents/agencies 
executing/managing a plurality of services and tasks collaboratively; wherein each work 
node has a task role identifier (identifier, agent name, service name) for specifying one 
of the first player and second player as responsible for execution of the work node 
reference A: Page 1, Paragraph 1, Line 6-7; Page 2, Paragraph 2, Lines 1-3; Page 2, 
Paragraph 4, Lines 1-2; Page 6, Paragraph 3, Lines 1-2; reference B: Page 2, 
Paragraph 2, Lines 1-3; Page 3, Paragraph 1, Lines 1-3; Figure 1, Page 3; Figure 2; 
reference D: Page 2, Paragraph 2, Lines 3-5; reference E: Last Paragraph, Page 147; 
Figure 1) and the template (process, process definitions) includes definitions (values, 
methods, sen/ice descriptions, etc.) and a (sharing) scope (hierarchy, topology, 
organizational relationship, social context, interrelationships, etc.;) that is one of public 
and process role specific (reference E: Bullets 3-6, Page 168; Paragraph 3, Page 172; 
"uses AM information about the agent's relationship with the potential service provider 
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(SAME-ORGANIZATION, EXTERNAL-ORGANIZATION) to set the strategy.". 
Paragraph 1, Page 174); 

- the first/second collaborative business process management executing an 
(first/second peer) instance of the collaborative business process (e.g. multiple 
collaborative process managers/agents/agencies executing an instance of the 
collaborative business process; reference A: Page 1, Paragraph 1, Line 6-7; Page 2, 
Paragraph 2, Lines 1-3; Page 2, Paragraph 4, Lines 1-2; Page 6, Paragraph 3, Lines 1- 
2; reference B: Page 2, Paragraph 2, Lines 1-3; Page 3, Paragraph 1. Lines 1-3; Figure 
1, Page 3; reference D: Page 2, Paragraph 2, Lines 3-5; reference E: Last Paragraph, 
Page 147; Paragraph 1, Page 148); 

- specifying the (sharing) scope of at least one process/communication 
(template, process definition) to keep data private between the first and second 
collaborative process managers (reference E: "The communication channel between 
any two negotiating agents is private.", Bullet 5, Page 168; reference E: Bullets 3-6, 
Page 168); 

- wherein the peer instances (first/second) form a logical execution instance 
(process instance; reference A: Figure 1; reference B: Section 2.2, Pages 6-8; 
Paragraph 2, Page 12; Bullets 1-3, Page 15; Figures 3, 7); and 

- communicate through messages for information exchange and synchronization 
(information exchange, negotiation, synchronization, communication, etc.; reference A: 
Page 2, Section 2.1, Paragraph 1, Lines 5-8; Section 2.2 Inter-agent communication, 
Pages 4-6; Page 7, Section 3, Paragraphs 1-2; Section 3.1 Communication, Pages 8-9; 
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reference B: Page 4, Paragraph 3, Communications Module; reference E: Last 
Paragraph, Page 163; Table 1). 

ADEPT further teaches that the system/method utilizes the well known 
techniques of encapsulation and abstraction in order to enable the collaborative process 
managers to hide internal/private business processes of the agents and expose/publicly 
provide only the services/processes necessary to complete the public collaborative 
process (reference E: "it is neither necessary for the agent requiring the "cost and 
design network" service to know how this is achieved, nor is it necessary for the 
department manager to known how to design a network or survey the geographical 
requirements." Paragraph 1, Page 155; Paragraph 2, Page 154). 
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Figures: Figure 1, reference E 
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ADEPT does not expressly teach process (template, service, etc.) having a 
(sharing) scope that is labeled public as claimed. 

Schuiz et al. teach defining a sharing scope for tempiated and role-specific 
business processes and public and private in an analogous art of multi-enterprise 
collaborative process management (business-to-business, B2B) for the purposes of 
keeping data (processes, internal operations, etc.) private between the plurality of 
collaborative process managers ("We propose a model for tiering business processes 
into organizations' private business processes and shared business processes that 
interconnect them. Private business processes can expose interaction points and 
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shared processes can link to these points so that an overall business process may span 
two or more organizations. The interaction points can selectively expose information 
about an organization's processes, process tasks and roles.", Abstract; Section 4.2 
Private and Shared Process Tiers, Pages 95-96; "One possibility is that a role from one 
organization is only given a permission to invoke an exposed private business process 
of another organization.", Paragraph 3. Column 2, Page 96). 

More generally Schuiz et al. teach a system/method for managing both the 
private and public (shared) business processes associated with multi-enterprise 
collaborative process management through enabling the interoperability of collaborative 
process managers (business process brokers, workflow engines, workflow management 
systems/methods; Abstract; Section 5 Business Process Framework Architecture, 
Pages 98-100; Figure 3). Schuiz et al. teach that the system/method enables 
organizations to keep certain aspects of the internal business processes private as well 
as providing role-based secure access to those exposed processes (Abstract; 
Paragraph 1 , Column 1, Page 93). Schuiz et al. teach the availability of a plurality of 
collaborative business process methods/systems wherein the methods/systems provide 
templated collaborative processes that include definitions (e.g. RosettaNet, EDOC, 
ebXML; Section 2 Process Interoperability Standards; Page 93) and that there are a 
plurality of well known methods (approaches) that enabling inter-process 
communication (messaging, data sharing, direct interaction/connection, etc.; Section 2.2 
Common Interfaces; Page 94). 
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It would have been obvious to one skilled in the art at the time of the invention 
that the system/method for managing collaborative business processes as taught by 
ADEPT would have benefited from denoting a processes (template, process definition, 
collaborative process manager interaction) sharing scope as public and/or private in 
view of the teachings of Schuiz et al.; the resultant system/method enabling entities to 
keep data (processes, internal operations, etc.) private between the plurality of 
collaborative process managers (Schuiz et al.: Abstract). 

Further it is noted that the phrases "public" and "sharing" in relation to the scope 
of a process merely represents non-functional descriptive material and is not 
functionally involved in the steps recited nor do they alter the recited structural 
elements. The recited method steps would be performed the same regardless of the 
specific label used to denote the scope of the process/process template. Further, the 
structural elements remain the same regardless of the specific label used to denote the 
scope of the process/process template. Thus, this descriptive material will not 
distinguish the claimed invention from the prior art in terms of patentability, see In re 
GulacK 703 F,2d 1381, 1385, 217 USPQ 401, 404 (Fed Cir 1983); In re Lowry, 32 
F,3d 1579, 32 USPQ2d 1031 (Fed, Cin 1994); MPEP 2106, 

Neither ADEPT nor Schultz et al. expressly teach using templates for keeping 
data private between two collaborative process managers (i.e. that the sharing scope is 
defined/specified in a template) as claimed. 
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Alturi et al. teach using templates for keeping data private between a plurality of 
collaborative process managers (workflow systems/subsystems, agents, engines, etc.; 
Authorization Template, Workflow Authorization Model; Last Paragraph, Page 2; 
Paragraph 2, Page 16; Last Paragraph, Page 19; Last Paragraph, Page 21; Footnote 
11, Page 21) in an analogous art of managing collaborative processes/workflows for the 
purposes of enforcing a security policies (template) in a workflow management system 
such as role-based, event-based, temporal/time-based authorization (Paragraph 1, 
Page 2) as well as enforcing workflow task/activity dependencies (control, value, 
external etc.; Paragraphs 3-4, Page 5). 

Alturi et al. further teach that most commercial workflow management systems 
enforce security based on organizational roles (Paragraph 4, Page 24). 

It would have been obvious to one skilled in the art at the time of the invention 
that the system and method for managing collaborative business processes as taught 
by the combination of ADEPT and Schuiz et al. would have benefited from - 
defining/specifying the sharing scope (security policy) using templates (e.g. 
authorization templates) in view of the teachings of Alturi et al.; the resultant 
system/method providing an authorization/security model for the inter-enterprise 
collaborative business processes (workflows) thereby ensuring such things as granting 
authorization to the collaborative process managers (agents) only when it is necessary 
and/or required (Alturi et al.: Paragraph 2, Page 16). 
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Regarding Claim 2 ADEPT teaches a computer-implemented method for 
managing collaborative multi-enterprise processes wherein the collaborative business 
processes is executed/managed by a plurality of collaborating agents/agencies 
(collaborative process managers) that provide (serve) and receive (client) services 
(tasks, etc.) and further wherein the collaborative process managers (agents) executing 
the business process comprise: (service execution, situation assessment, 
communication, and interaction modules; reference A: Section 3, Pages 7-11; Figures 
1-3; negotiation, resource management and enactment modules; reference B: Figure 7; 
reference D: Section 4, Pages 8-12; reference E: Last Paragraph, Page 178; 
Paragraph 1, Page 179; Bullet 1, Page 180): 

- a collaborative process manager (agent) receiving a task (request for service, 
message; reference D: Steps 1-2, Page 10); 

- a collaborative process manager determining if the task is its responsibility 
(situation assessment, negotiation, interaction module; evaluate proposals; reference B: 
Paragraph 4, Page 4; reference D: Steps 2-4; Pages 10-11); 

- when the task is the responsibility of the collaborative process manager, 
executing the current task (enactment, action, accepting proposal, providing/executing 
request service; invoke service; service level agreement, contract, etc.; reference B: 
Pages 3, 5; Paragraph 3, Page 4; reference D: Step 4, Pages 10-11); and 

- when the task is not the responsibility of the collaborative process manager, not 
executing (ignoring, forwarding, rejecting, delegating, etc.) the task (reference B: 
Paragraph 4, Page 4; reference D: Step 3, Pages 10-11). 
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Regarding Claim 3 ADEPT teaches a computer-implemented method for 
managing collaborative multi-enterprise processes wherein the when task is the 
responsibility of the collaborative process manager (agent), executing the task further 
comprises (reference B: Sections 2.1-2.2, Pages 4-8; reference D: Section 4, Pages 8- 
12; reference E: Pages 161-162): 

- scheduling the task (reference B: Interaction Module, Pages 4-5; reference B: 
situation assessment module. Paragraph 1, Page 5); 

- dispatching the task for execution (fonA^arding, delegating, resource 
management; reference A: Paragraph 1, Page 8; reference D: Section 4.2, Pages 10- 
11, Steps 1-4); 

- upon completion of task generating a message (service results; reference B: 
Paragraph 3, Page 4; reference D: return, delivery. Steps 3 and 5; Pages 10-11); and 

- sending a message (service request) to another collaborative process manager 
(agent/agency; reference B: situation assessment module, communication module, 
interaction module. Pages 4-5; Figure 2; reference D: Section 4.2, Pages 10-11). 

z 

Regarding Claim 4 ADEPT teaches a computer-implemented method for 
managing collaborative multi-enterprise processes wherein when the task is not the 
responsibility of the collaborative process manager, not executing (invoking) the task 
further comprises (reference B: Sections 2.1-2.2. Pages 4-8; reference D: Section 4, 
Pages 8-12): 
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- not executing the task (ignore, rejecting proposal/service request. 
fonA/arding/delegating; reference B: Paragraphs 3-4, Page 4); 

- waiting for a message (service request) from another collaborative process 
manager (agent/agency; reference D: Steps 1-4, Pages 10-11); and 

- receiving a message (service request) from another collaborative process 
manager (agent/agency; reference D: Steps 1-4, Pages 10-11). 

ADEPT further teaches that the system utilizes messaging/messages to 
request/provide services amongst the plurality of collaborative process 
managers/agents wherein the agents to send/receive messages (service requests, 
service negotiation; reference B: Paragraph 3, Page 4), wait for messages (service 
requests, proposals), review/analyze messages (situation assessment, proposal 
evaluation), act upon messages based on the analysis and send messages (status, 
updates, etc.) after the action/task has been completed (reference B: Pages 4-5; 
reference D: Steps 1-4, Pages 10-11; reference A: Page 2, Section 2.1, Paragraph 1, 
Lines 5-8; Section 2.2 Inter-agent communication, Pages 4-6; Page 7, Section 3, 
Paragraphs 1-2; Section 3.1 Communication, Pages 8-9; reference B: Page 4, 
Paragraph 3, Communications Module). 

Regarding Claim 6 ADEPT teaches a computer-implemented method for 
managing collaborative multi-enterprise processes wherein the system/method uses a 
key (cooperation key, handle, identifier, symbol, etc.) to identify a logical instance of the 
collaborative business process and to correlate and synchronize multiple peer instances 
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of the execution of a single collaborative business process (reference A: Section 3.1, 
Pages 8-9; Figure 4; reference D: Section 4, Pages 8-1 1). 

Regarding Claim 7 ADEPT teaches a computer-implemented method for 
managing collaborative multi-enterprise processes employing messages for 
synchronizing the peer process instances (collaborative agents/agencies) and for 
exchanging data between process instances; wherein each message includes 
(reference A: Page 2, Section 2.1, Paragraph 1, Lines 5-8; Section 2.2 Inter-agent 
communication, Pages 4-6; Page 7, Section 3, Paragraphs 1-2; Section 3.1 
Communication, Pages 8-9; reference B: Page 4, Paragraph 3, Communications 
Module): 

- a key (cooperation key, handle, identifier, etc.) for specifying (identifying, 
accessing, requesting, participating in) a logical process instance (conversation ID, 
informodellD, etc.; reference A: Page 9; Figure 4; reference B: agent negotiation. 
Section 2.3, Page 8); 

- a local handle (name, address, agentjd, registered agents, identity etc.) of the 
process instance and task (message, service request, find/location agent; reference A: 
Paragraph 2, Page 8; Paragraph 3; Figure 4; reference B: Figure 5; reference D: Steps 
1-2, Pages 10-11; reference E: Last Paragraph, Page 156); 

- a status (service results, content, body; reference D: Section 4.1, Page 8; 
Section 4.2, Steps 1-4, Pages 10-11; reference E:, Last Paragraph, Page 158) and 



Application/Control Number: 09/823,581 Page 25 

Art Unit: 3623 

- process data (sub-packet, packet, group, etc.) of passed to a task (message, 
process manager; reference A: Paragraph 3, Page 9, Figure 4; reference B: Section 
2.2, Page 6, Figures 3-4; reference E: Pages 157-158; Figure 5). 

Regarding Claim 8 ADEPT teaches a computer-implemented method for 
managing collaborative multi-enterprise processes wherein a list of process roles (roles, 
agencies) for indicating logical participants of the collaborative process; wherein each 
work node has a task role that matches one of the process roles; and wherein a peer 
process having a process role that matches the task role of a work node is responsible 
for executing the work node (reference A: Pages 1-11; Figures 1-4; reference B: Pages 
1-12; Figures 1-2, 6-7 and 10; reference D: Pages 1-3; Figures 1-5). 

Regarding Claim 9 ADEPT teaches a computer-implemented method for 
managing collaborative multi-enterprise processes providing a collaborative process 
definition language (service description, service language, common communication 
language/mechanism, process description, process modeling) for defining the 
collaborative business process (reference A: Section 2.1, Pages 4-6; reference B: 
Section 2.2, Pages 6-8; reference D: Section 4.1, Pages 8-9; reference E: Paragraph 
1, Page 148; Last Paragraph, Page 155; Figure 1). 

Regarding Claim 1 1 ADEPT teaches a computer-implemented method for 
managing multi-enterprise collaborative processes wherein the step of specifying the 
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sharing scope of at least one template (process) includes setting the sharing scope as 
public (open, shared, accessible, shared information, etc.) wherein a data object is 
public (accessible, shared, etc.; information model, information sharing, etc.; reference 
B: Section 2.2, Pages 6-7; Figures 3-4; reference D: Section 4.1, Pages 8-9; Step 3, 
Page 8; reference E: Bullets 3-6, Page 168; Paragraph 3, Page 172; Paragraph 1, 
Page 174). 

Regarding Claims 12 and 13 ADEPT teaches a computer-implemented method 
for managing multi-enterprise collaborative processes wherein specifying the (sharing) 
scope further comprises setting the (sharing) scope as process-role specific for a 
particular process role (two or more) wherein the process is accessible only to the 
process-role specified (reference E: Bullets 3-6, Page 168; Paragraph 3, Page 172; 
Paragraph 1, Page 174). 
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6. Claim 5 is rejected under 35 U.S.C. 103(a) as being unpatentable over Advanced 
Decision Environment for Process Tasks (ADEPT) features, capabilities and/or 
characteristics of ADEPT being disclosed in at least the following references: 

I. Norman, T.J., et al. Designing and implementing a multi-agent architecture for 
business process management (1996) herein after reference A. 

II. Jennings, N.R. et al.. Using Intelligent Agents to Manage Business Processes 
(1996) herein after reference B. 

III. Alty, J.L. et al., Advanced Decision Environment for Process Tasks: 
Overview and Architecture (1994) herein after reference D. 

IV. Jennings, N.R. et al., Autonomous Agents for Business Process 
Management (2000), herein after reference E. 

in view of Schuiz et al., Architecting Cross-Organizational B2B Integration (2000) 
in view of Atluri et al., Enforcing Mandatory and Discretionary Security in Workflow 
Management Systems (1996) as applied to claims 1-4, 6-9 and 11-13 above and further 

in view-of Workflow Management-Coalition Workflow Standard Interoperability (1998), ^ ^ 

herein after WFMC. 

Regarding Claim 5 ADEPT teaches a computer-implemented method for 
managing a collaborative multi-enterprise process, as discussed above, wherein the 
step of determining the current task is not the responsibility of the collaborative (first) 
process manager not executing the task further comprises (error/exception handling; 
start, stop, resume, renegotiate processes/collaborations having errors/exceptions; 

■» 



Application/Control Number: 09/823,581 Page 28 

Art Unit: 3623 

reference B: Paragraphs 3-4, Page 4; Paragraphs 1-2, Page 5; reference E: 
Paragraphs 2-3, Page 163): 

- evaluating the current task return message to determined whether an 
error/exception has occurred; 

- when an error/exception has occurred, queuing (saving, holding, etc.) the task 
(return message) for later processing; and 

- when an error/exception has not occurred processing the next task by 
employing the return message. 

ADEPT does not expressly teach that the error/exception is an out-of-order 
condition as claimed. 

WFMC further teaches detecting and acting upon a plurality of message errors 
including but not limited to "out of sequence messages", "out-of-conversation", lost 
messages, duplicate messages and the like (Pages 8, 13-14, error message 207 invalid 
sequence) via the management of "conversations" between the two or more workflow 
management systems (process synchronization) in an analogous art of process 
management for the purposes of enabling multiple process management systems 
(workflow management systems) to interoperate/collaborate (Sections 2 and 5, Page 5). 

It would have been obvious to one skilled in the art that the inter-enterprise 
collaborative process management system as taught by ADEPT would have benefited 



Application/Control Number: 09/823,581 Page 29 

Art Unit: 3623 

from detecting and acting upon out of sequence/order messages being exchanged 
amongst the collaborative process managers (i.e. conversation management) in view of 
the teachings of WFMC; the resultant system/method enabling multiple process 
management systems (workflow management systems) to interoperate/collaborate 
(WFMC: Sections 2 and 5, Page 5). 
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7. Claims 14-15 and 17-20 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Advanced Decision Environment for Process Tasks (ADEPT) 
features, capabilities and/or characteristics of ADEPT being disclosed in at least the 
following references: 

I. Norman, T.J., et al. Designing and implementing a multi-agent architecture for 
business process management (1996) herein after reference A. 

II. Jennings, N.R. et al.. Using Intelligent Agents to Manage Business Processes 
(1996) herein after reference B. 

III. Alty, J.L. et al., Advanced Decision Environment for Process Tasks: 
Overview and Architecture (1994) herein after reference D. 

IV. Jennings, N.R. et al., Autonomous Agents for Business Process 
Management (2000), herein after reference E. 

in view of Management Coalition Workflow Standard Interoperability (1998), 
herein after WFMC. 

Regarding Claim 14 ADEPT teaches a system for allowing a first player in a first 
enterprise to collaborate with a second player in a second enterprise comprising 
(reference A: Pages 1-11; Figures 1-4; reference B: Pages 1-12; Figures 1-2, 6-7 and 
10; reference D: Pages 1-3; Figures 1-5): 

- a collaborative business process definition specified by a collaborative process 
definition language (reference A: Paragraph 4, Page 2; Figure 1) and based on an inter- 
enterprise business collaboration protocol ( SDL, ACL, etc.; reference E: Last 
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Paragraph Page 156; Last Paragraph, Page 163), the collaborative business process 
definition having a plurality of work nodes (collaborative agents providing and 
requesting tasks and services; reference A: Paragraph 1, Page 4; Figure 2), each work 
node having a task role (reference B: "sales", "marketing", Paragraphs 1-2, Page 3; 
Figure 1); 

- first/second of collaborative process managers executing first/second (peer) 
process instances of the collaborative business process (definition), the one or more 
peer process instances having a role (services agents provide/receive, agents 
representing departments, organizations, individuals, etc.); wherein the one or more 
peer process instances is responsible only for work nodes (agents/agencies) that have 
a role (services, tasks, etc.) that matches (related to, associated with, collaborate with) 
the role of the one or more peer instances (hierarchy of agents/agencies that 
collaboratively execute one or more instances/executions of the business process; 
reference A: Paragraph 3, Page 3; Footnote 1; Page 3; Paragraphs 1-2, Page 4; 
Paragraph 5, Page 2; Figure 2; reference B: Figure 2); 

- a peer-to-peer communication mechanism for enabling data exchange and 
synchronization between the plurality of (first and second) peer process instances 
(reference A: Page 2, Section 2.1, Paragraph 1, Lines 5-8; Section 2.2 Inter-agent 
communication. Pages 4-6; Page 7, Section 3, Paragraphs 1-2; Section 3.1 
Communication, Pages 8-9; reference B: Page 4, Paragraph 3, Communications 
Module); and 
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- an error/exception handling mechanism wherein collaborative processes can 
be terminated, stopped, started, resume and/or renegotiated based on the 
error/exception (reference B: Paragraphs 3-4, Page 4; Paragraphs 1-3, Page 5; 
reference E: Paragraphs 2-3, Page 163). 

ADEPT does not expressly teach that the system comprises an out-of-order 
handler mechanism for receiving messages from other collaborative process managers, 
determining whether messages are received out of order and when messages are 
received out of order halting execution and when messages are not out of order 
continuing the execution as claimed. 

WFMC teach an out-of-order handler mechanism for receiving messages from 
other collaborative process managers, determining whether messages are received out 
of order ("out of sequence messages", "out-of-conversation", lost messages, duplicate 
messages and the like (Pages 8, 13-14, error message 207 invalid sequence) and when 
messages are received out of order halting execution and when messages are not out 
of order continuing the execution in an analogous art of collaborative process 
management for the purposes of for the purposes of enabling multiple process 
management systems (workflow management systems) to interoperate/collaborate 
(Sections 2 and 5, Page 5). 
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It would have been obvious to one skilled in the art at the time of the invention 
that the system for allowing a first player in a first enterprise to collaborate with a 
second player in a second enterprise as taught by ADEPT would have benefited from 
incorporating an out-of-order handler mechanism for receiving messages from other 
collaborative process managers, determining whether messages are received out of 
order in view of the teachings of WFMC the resultant system/method enabling process 
management systems/methods to interoperate/collaborate (WFMC: Sections 2 and 5, 
Page 5). 

Regarding Claim 15 ADEPT a system for allowing a first player in a first 
enterprise to collaborate with a second player in a second enterprise further comprising 
a communication module (message generator) for generating a plurality of messages 
for the collaborative process manager (service execution, situation assessment, 
communication, and interaction modules; reference A: Section 3, Pages 7-11; Figures 
1-3; reference B: Figure 7; negotiation, resource management and enactment modules; 
reference D: Section 4, Pages 8-12). 

Regarding Claim 17 ADEPT a system for allowing a first player in a first 
enterprise to collaborate with a second player in a second enterprise further comprising 
a private (secure, confidential, etc.) sub-process (processes, services, sub-services) 
manager (agents, agencies, virtual agency, sub-agents) selectively making process 
data (objects, services, messages) private (confidential, secure, etc.) to a particular 
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collaborative process manager (reference E: "The communication channel between 
any two negotiating agents is private.", Bullet 5, Page 168; Bullets 3-6, Page 168). 

Regarding Claim 18 ADEPT a system for allowing a first player in a first 
enterprise to collaborate with a second player in a second enterprise further comprising 
a role determination module (situation assessment module, interaction module, service 
execution module; reference B: section 2.1, Pages 4-5) for receiving the task (request 
for service, message; reference D: Steps 1-2, Page 10), for determining whether the 
current task is the responsibility of the collaborative process manager (situation 
assessment, negotiation, interaction module; evaluate proposals; reference B: 
Paragraph 4, Page 4; reference D: Steps 2-4; Pages 10-11), when the current task is 
the responsibility of the collaborative process manager (enactment, action, accepting 
proposal, providing/executing request service; invoke service; service level agreement, 
contract, etc.; reference B: Pages 3, 5; Paragraph 3, Page 4; reference D: Step 4, 
Pages 10-11), for scheduling and dispatching the task for execution, when the task is 
not the responsibility of the collaborative process manager, not executing the task 
(service execution, situation assessment, communication, and interaction modules; 
(reference B: Paragraph 4, Page 4; reference D: Step 3, Pages 10-11; reference A: 
Section 3, Pages 7-11; Figures 1-3; reference B: Figure 7; negotiation, resource 
management and enactment modules). 
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Regarding Claim 19 ADEPT a system for allowing a first player in a first 
enterprise to collaborate with a second player in a second enterprise employing 
messages for synchronizing the peer process instances (collaborative agents/agencies) 
and for exchanging data between process instances; wherein each message includes 
(reference A: Page 2, Section 2.1, Paragraph 1, Lines 5-8; Section 2.2 Inter-agent 
communication, Pages 4-6; Page 7, Section 3, Paragraphs 1-2; Section 3.1 
Communication, Pages 8-9; reference B: Page 4, Paragraph 3, Communications 
Module): 

- a key (cooperation key, handle, identifier, etc.) for specifying (identifying, 
accessing, requesting, participating in) a logical process instance (conversationID, 
informodellD, etc.; reference A: Page 9; Figure 4; reference B: agent negotiation, 
Section 2.3, Page 8); 

- a local handle (name, address, agentjd, registered agents, identity etc.) of the 
process instance and task (message, service request, find/location agent; reference A: 
Paragraph 2, Page 8; Paragraph 3; Figure 4; reference B: Figure 5; reference D: Steps 
1-2, Pages 10-11); 

- a status (service results, content, body; reference D: Section 4.1, Page 8; 
Section 4.2, Steps 1-4, Pages 10-11) and 

- process data (sub-packet, packet, group, etc.) of passed to a task (message, 
process manager; reference A: Paragraph 3, Page 9, Figure 4; reference B: Section 
2.2, Page 6, Figures 3-4). 
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Regarding Claim 20 ADEPT teaches a system for allowing a first player in a first 
enterprise to collaborate with a second player in a second enterprise wherein a list of 
process roles (roles, agencies) for indicating logical participants of the collaborative 
process; wherein each work node has a task role that matches one of the process roles; 
and wherein a peer process having a process role that matches the task role of a work 
node is responsible for executing the work node (reference A: Pages 1-11; Figures 1-4; 
reference B: Pages 1-12; Figures 1-2, 6-7 and 10; reference D: Pages 1-3; Figures 1-5). 
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Conclusion 

The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 

- Klemba et al., U.S. Patent No. 6,035,399, teach a system and method for 
administering security policies between two or more enterprises. 

- Chen et al., U.S. Patent No. 6,983,395, teach a mutli-agent collaborative 
workflow system and method. 

- Woo et a!.. Authorization in Distributed Systems (1992) teach a system and 
method for managing the sharing scope (access control, security, authorization) for one 
or more systems wherein the authorization requirements/constraints are defined in one 
or more templates (policies). 

- Alturi et a!.. An Authorization Model for Workflows (1996) teach a system and 
method for providing inter-enterprise workflow security through a Workflow 
Authorization Model wherein authorization requirements/constraints/policies are defined 
in one or more Authorization Templates which define role, task and temporal 
authorizations for the collaborating systems/entities/agents. 

- Chen et al.. Dynamic Agents (1999) teach a dynamic agent infrastructure 
(system and method) for dynamic distributed systems such as inter-enterprise 
collaborative workflows comprising dynamic service provisioning and message-enabled 
agent cooperation through the use of messaging queues. 

- Griss, Martin, My Agent Will Call Your Agent... (1999) teaches a multi-agent 
collaborative workflow system and method that utilizes well known message-based 
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middleware to provide message sequencing and conversational control wherein the 
collaborative agents assume a legal (in-order) sequence of messages as defined in 
process templates and watch for and monitor for compliance with the message 
sequences (i.e. look for out-of-order messages). 

- Dayal et al., Business Process Coordination: State of the Art, Trends and Open 
Issues (2001) teaches a plurality of well known business coordination (e.g. inter- 
enterprise workflow) systems, method and standards (ebXML, WFMC, UDDI, etc.) as 
well as the well known utilization of messaging middleware, message brokers and 
transaction queue managers that enable collaborative workflows 
cooperate/coordinate/communicate. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Scott L. Jarrett whose telephone number is (571) 272- 
7033. The examiner can normally be reached on Monday-Friday, 8:00AM - 5:00PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Hafiz Tariq can be reached on (571) 272-6729. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 





